Conventional migration and inversion methods involve the correlation of forward and backward propagated wavefields to obtain images representative of subsurface characteristics. Examples of such methods include reverse-time migration, differential semblance velocity analysis and waveform inversion. These methods require that forward propagated wavefields be accessed in reverse order, in lockstep with the adjoint backward propagated wavefields at each time step.
With respect to reverse time migration, for example, the requirement of simultaneous availability of both the forward and backward propagated wavefields at each time step poses significant computational challenges for large datasets. These challenges are in part due to the need to access the forward propagating wavefield in reverse order, while accessing the backward propagating wavefield in reverse order to correlate with the forward propagating wavefield. Conventional solutions to address the computational challenges strategy include repeated forward propagation of the wavefield to the n-th time step, minimizing the re-computation ratio by optimal wavefield storage strategies and interpolation, backward propagating the already forward propagated source wavefield. See for example Eric Dussaud, et al, Computational strategies for reverse-time migration, SEG Las Vegas 2008 Annual Meeting, and Symes, William W. Reverse Time Migration with Optimal Checkpointing, Geophysics, 72, no. 5, SM213-SM221, 2007.
The RTM algorithm as implemented in the present work addresses this requirement by storing and subsequently retrieving the forward wavefield. The amount of data and particularly the rate at which this data is produced (and needs to be stored/retrieved) makes the use of data compression techniques necessary. Appropriate data compression schemes impose an additional computational burden, therefore reducing the performance of the overall application. By moving the core computational workload of the RTM application to the co-processor, CPU resources are made available for compression/decompression, applying imaging conditions and disk I/O, making this scheme computationally efficient and overall viable.
Conventional approaches to these limitations, particularly on accelerator platforms, often tradeoff the computation, and/or re-computation, of wavefields, and the storage of the recorded wavefield data in the memory hierarchy, including RAM, local hard drives and network-attached storage. This tradeoff is a function of both hardware and algorithmic considerations. The introduction of re-computation in lieu of (slow) storage is overall a favorable approach on platforms that excel in computational speed, i.e. on accelerators such as GPUs and FPGAs. However, any additional computation does have a negative impact on the overall performance of the application. The optimal implementation would therefore eliminate the performance limitation of wavefield storage & retrieval without increasing the computational load.
Adjoint state problems, such as reverse-time migration, pose serious computational problems for large datasets and manifest themselves in the classical tradeoff between computation and storage. Algorithms realizing a particular tradeoff will have their computational performance limited by the particular tradeoff. For example, storage may be a limiting factor in many algorithms and hardware storage access rate may become the de facto computational rate for a given application. Other algorithms may be designed to balance the computation versus storage tradeoff in such a way that the computational and storage capacities of the system are optimally stressed. For best performance, algorithms should be adaptively designed to optimally use the computational and memory structure of a given new hardware, such as graphics processing units (GPU) or field-programmable gate arrays (FPGA).
As such, a need exists to more efficiently process seismic wavefield data to generate images of a subsurface region of interest in a more timely and cost efficient manner. In particular, the rate at which the required computational operations are carried out needs to be improved beyond. At the same time, the auxiliary components of the method (data storage/retrieval, data transfer between components involved) need to be optimized and improved accordingly to avoid the creation of bottlenecks that would limit the overall effectiveness of the application.